FIG. 1 shows a schematic diagram of how a typical ATM application communicates with the devices installed in the ATM using the CEN (the European Committee for Standardization) XFS API (application programming interface). The ATM may have a number of devices 101-103 installed, such as a dispenser, a keypad and a receipt printer, with each device having an associated service provider 104-106. An ATM application 107 can communicate with one of these devices via an XFS Manager 108. The ATM application 107 makes a call to the XFS Manager 108 to open a session with one of the service providers 104-106 using a well-known name for the associated device, referred to as the ‘logical service name’. The XFS Manager accesses a registry to identify the service provider corresponding to the particular logical service name included within the call and then opens a session with the relevant service provider. The XFS Manager 108 then acts as an intermediary between the ATM application 107 and the relevant service provider.
In an example, as shown in FIG. 1, the services for the cash dispenser module 101 are provided by service provider 1 104. A session with this service provider 104 may be opened using a call which includes the logical service name ‘CurrencyDispenser’.
Traditionally, the logical service names are hard-coded within the ATM application, such that there is a fixed one to one relationship between a logical service name and a service provider. For example, an ATM application would always open a cash dispensing module session using the ‘CurrencyDispenser’ logical service name. Problems arise, however, where different vendors use different names for equivalent devices (e.g. ‘Receipt_Printer’ and ‘ReceiptPrinter’), because then the application has to be tailored depending on the vendor. Additionally problems occur where a single vendor supports more than one variant of a given device (e.g. more than one keyboard) because then there may be more than one logical service name for equivalent devices which must be supported.